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The User Class Option for DHCP 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2000). All Rights Reserved. 
Abstract 


This option is used by a Dynamic Host Configuration Protocol (DHCP) 
client to optionally identify the type or category of user or 
applications it represents. The information contained in this option 
is an opaque field that represents the user class of which the client 
is a member. Based on this class, a DHCP server selects the 
appropriate address pool to assign an address to the client and the 
appropriate configuration parameters. This option should be 
configurable by a user. 


1. Introduction 


DHCP administrators may define specific user class identifiers to 
convey information about a client’s software configuration or about 
its user’s preferences. For example, the User Class option can be 
used to configure all clients of people in the accounting department 
with a different printer than clients of people in the marketing 
department. 
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Requirements Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [3]. 


DHCP Terminology 


o "DHCP client" 
A DHCP client or "client" is an Internet host using DHCP to obtain 
configuration parameters such as a network address. 


o “DHCP server" 
A DHCP server or "Server" is an Internet host that returns 
configuration parameters to DHCP clients. 


o "binding" 
A binding is a collection of configuration parameters, including at 
least an IP address, associated with or "bound to" a DHCP client. 
Bindings are managed by DHCP servers. 


User Class option 


This option is used by a DHCP client to optionally identify the type 
or category of user or applications it represents. A DHCP server 
uses the User Class option to choose the address pool it allocates an 
address from and/or to select any other configuration option. 


This option is a DHCP option [1, 2]. 


This option MAY carry multiple User Classes. Servers may interpret 
the meanings of multiple class specifications in an implementation 
dependent or configuration dependent manner, and so the use of 
multiple classes by a DHCP client should be based on the specific 
server implementation and configuration which will be used to process 
that User class option. 


The format of this option is as follows: 


Code Len Value 

+----- +----- +--------------------- 2. cot 
| 77 | N User Class Data (’Len’ octets) | 
+----- +----- +---------------—-—---— Aona cot 


where Value consists of one or more instances of User Class Data. 
Each instance of User Class Data is formatted as follows: 


Stump, et al. Standards Track [Page 2] 


RFC 3004 The User Class Option for DHCP November 2000 


UC_Len_i User_Class_Data_i 

+-------- 4+------------------------ sepa GS 
Li | Opaque-Data (’UC_Len_i’ octets) | 

+-------- 4+------------------------ aoe a + 


Each User Class value (User_Class_Data_i) is indicated as an opaque 
field. The value in UC_Len_i does not include the length field 
itself and MUST be non-zero. Let m be the number of User Classes 
carried in the option. The length of the option as specified in Len 
must be the sum of the lengths of each of the class names plus m: 
Len= UC_Len_1 + UC_Len_2 + ... + UC_Len_m+m. If any instances of 
User Class Data are present, the minimum value of Len is two (Len = 
UC_Len_1 + 1 = 1 + 1 = 2). 


The Code for this option is 77. 


A server that is not equipped to interpret any given user class 
specified by a client MUST ignore it (although it may be reported). 
If a server recognizes one or more user classes specified by the 
client, but does not recognize one or more other user classes 
specified by the client, the server MAY use the user classes it 
recognizes. 


DHCP clients implementing this option SHOULD allow users to enter one 
or more user class values. 


5. IANA Considerations 


Option 77, which IANA has already assigned for this purpose, should 
be used as the User Class Option for DHCP. 


6. Security Considerations 


DHCP currently provides no authentication or security mechanisms. 
Potential exposures to attack are discussed is section 7 of the 
protocol specification [1]. 


This lack of authentication mechanism means that a DHCP server cannot 
check if a client or user is authorized to use a given User Class. 
This introduces an obvious vulnerability when using the User Class 
option. For example, if the User Class is used to give out a special 
parameter (e.g., a particular database server), there is no way to 
authenticate a client and it is therefore impossible to check if a 
client is authorized to use this parameter. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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